Communication systems link together two communication devices so that the devices can send information to each other in a call or other communication event. Information may include voice, text, images or video.
One such communication system is a peer to peer communication system, in which a plurality of end users can be connected for communication purposes via a communications structure such as the internet. The communications structure is substantially decentralized with regard to communication route switching therein for connecting the end users, which means that the end users can often establish their own communication routes through the structure.
The communication structure of a peer to peer system may be formed by a large number of distributed nodes. The distributed nodes may not necessarily be owned or operated by the system provider. Instead, the nodes may be clients running software that programs them to behave as a node in the communication system. The communication structure can thus be created by essentially “borrowing” a small amount of computing resources from millions of devices. A user can then access the peer to peer system via any one of those devices. In such systems, it is no longer necessary for the user to access a centralized server in order to gain access to the system as a whole.
The signaling required to set up a communication between two client devices in a peer to peer system is typically routed via one or more nodes. These nodes may act as relays or proxies by forwarding requests from a client on towards their destinations. An example is shown in FIG. 1.
FIG. 1 shows a communication system 101 comprising a first client A (102) that wants to communicate with a second client B (103). To establish the call, client A sends a call request to node 104 identifying client B. The identity might be, for example, a URI. Node 104 queries database 105 for the identity of the node 106 to which the call request should be routed. Database 105 may be a Domain Name Service (DNS). The database 105 returns location details for node 106. These details could include, for example, an IP address and port number for node 106. Node 104 uses the address details returned by the database look-up to forward the call request to node 106. Node 106 then looks-up the location of client B in another database 107, such as a location service. Finally, the call request is forwarded to client B.
The Session Initiation Protocol (SIP) is an example of a protocol that may be used to establish connections in a similar way to that shown in FIG. 1. SIP is a signaling protocol used to create, modify and terminate sessions between one or more participants. The sessions may include internet telephone calls, multimedia distribution and multimedia conferences. SIP uses proxies (a form of relay) to relay the signaling messages that are used to set-up the connection. The document “Session Initiation Protocol (SIP): Locating SIP Servers” (rfc 3263) describes how SIP proxies use DNS procedures to identify other proxies in the system. This includes one proxy for identifying a second proxy on the route towards a message's destination (see e.g. FIG. 1) and a back-up for the first proxy in case it fails after forwarding the request. This back-up proxy is located in the same level of the hierarchy as the first proxy.
SIP also allows clients to allocate multiple SIP proxies for redundancy. The multiple proxies may be defined by an outbound-proxy-set. The client attempts to maintain a direct flow with each of the proxies in the outbound proxy set so that it can detect when a flow fails. Since detecting a failure takes time there is a window in which incoming requests might be missed. By maintaining direct flows with multiple proxies, the client can protect against missed requests in the event of a flow failure (see “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) (rfc 5626)). Similarly to the back-up proxies described above, the proxies in the outbound proxy set are all located in the same level of the hierarchy.
Once a call is established, it may continue over a direct connection. An example is calls that involve the transfer of media data. Typically this requires each participant in the call to know the system location of all the other participants so that packets can be addressed appropriately. A call that proceeds over a direct connection may be set up via other nodes in the communication system (such as proxies 104 and 106 in FIG. 1, for example), but those nodes do not take an active part in the connection. Nodes whose active role is limited to performing an introductory service for the clients but which do not play an active role once the connection has been established are known as rendezvous nodes.
For some types of call, it is not possible to establish a direct connection between the participants An example is a call in which one or more of the participants is located behind a Network Address translator (NAT). The NAT is often implemented by a router that modifies system address information in packet headers for the purpose of remapping one address space into another. NATs may be used to implement firewalls, improve privacy and enable a plurality of devices to be connected to an external communication system via a single address. Some types of NATs prevent direct connections between clients located behind different NATs. For such calls the connection can only continue with the active participation of a relay node.
Protocols such as SIP that are based on offer/answer are difficult to operate through NATs. This is because such protocols often aim to establish a flow of media packets and thus carry the IP addresses and ports of media sources and sinks within their messages, which is problematic through NAT. Also, the protocols typically seek to create a media flow directly between participants, so that there is no application layer intermediary between them. This is difficult to accomplish through NAT.
SIP uses another protocol, known as the Interactivity Connectivity Establishment protocol (ICE), to negotiate the media relays that may be required to provide NAT traversal (see “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Transversal for Offer/Answer Protocols” (draft-ietf-mmusic-ice) and “Traversal Using Relays Around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)” (draft-ietf-behave-turn)). According to ICE, each end of the dialogue is responsible for locating a relay that is globally reachable and which is willing to relay traffic for it. The signaling is handled by proxies, in a similar way to that described above in FIG. 1.
An example of a client located behind a NAT is shown in FIG. 2. In FIG. 2, client A (201) wishes to contact client B (205) via a peer to peer communication system (204) such as the internet. Client A is located behind NAT 202. Client B may similarly be located behind a NAT and/or relay (not shown). In order for client A to set-up a connection with client B it must first establish a set of candidates. A candidate is a transport address that the client is entitled to use. One viable candidate is a transport address obtained directly from a local interface. The protocol also provides for clients to obtain additional candidates from one or more system nodes. A client wishing to establish a connection over an external communication system such as the internet should obtain a relayed candidate. Client A therefore sends an allocation request to relay 203. As client A is located behind a NAT, the NAT 202 first creates a binding mapping the address of the client X:x to an IP address and port on the public side of the NAT (X1′:x1′). X1′:x1′ is known as the server reflexive candidate. There may be multiple NATs located between the client and the relay.
The allocate request is then received by the relay, which, if it is willing and able to accept the request, will allocate a port Y from its local IP address Y to client A. Y:y is known as the relayed candidate. The relay will return an allocate response to client A informing it of the relayed candidate and the server reflexive candidate. If there are multiple NATs located between the client and the relay, the allocate response will only include the server reflexive candidate corresponding to the outermost NAT, i.e. the NAT closest to the relay.
When the connection between client A and client B is established, the relay acts to forward packets between A and B. B sends traffic to the relay at Y:y, the relay forwards that traffic to X1′:x1′. The forwarded traffic then passes through the NAT where it is mapped to X:x and delivered to A.
There are many different ways for a client to locate an appropriate relay for a connection across a peer to peer communication system. Relays may be used for many different functions, including NAT traversal, performance improvement through alternative route selection, transcoding etc. A specific relay may be chosen based on proximity to the client, performance etc. “Discovery of In-Band Streaming Services in Peer-to-Peer Overlays” by Buford et al describes allocating relays on the basis of a coordinate location system, load distribution and the capacity and availability of individual relays.